Skip to content

Conversation

@evis
Copy link

@evis evis commented Nov 18, 2025

When .bazelproject file is not recognized as ProjectView file type, it gets treated as plain text and parsed incorrectly.

Previously: Silent fallback to default project view
Now: Clear error + auto-fix attempt + manual instructions

This prevents the issue where custom .bazelproject were ignored, causing full workspace builds instead of targeted builds.

Fixes: BAZEL-2674

When .bazelproject file is not recognized as ProjectView file type,
it gets treated as plain text and parsed incorrectly.

Previously: Silent fallback to default project view
Now: Clear error + auto-fix attempt + manual instructions

This prevents the issue where custom .bazelproject
were ignored, causing full workspace builds instead of targeted builds.

Fixes: BAZEL-2674
@jastice jastice requested review from aehlig, mhz47 and noxvost January 11, 2026 13:36
@aehlig
Copy link
Member

aehlig commented Jan 12, 2026

Thanks for your contribution and sorry that the pull request was left unanswered for so long. As the file has changed quite a bit on the main branch since then, would you mind rebasing it on the main branch? I think it makes more sense to get it in at head rather than to 252 only.

* @param virtualFile the .bazelproject file that needs to be fixed
* @return true if auto-fix succeeded, false if it failed
*/
private fun tryAutoFixFileTypeRegistration(virtualFile: VirtualFile): Boolean {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me this method breaks SRP. It doesn't check that file is of necessary type, and makes a lot of assumes.
I would suggests to change this method to do fileTypeManager.associatePattern(ProjectViewFileType, "*.bazelproject") only, and forcinf virtualFile refresh outside upon success.

} catch (e: ProcessCanceledException) {
throw e
} catch (e: Exception) {
log.warn("Auto-fix failed with exception: ${e.message}", e)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You split problem for user into two parts: issue the line into logs, and throwing the exception upon returning false with loss of failure context. Wouldn't it be better to throw outer IllegalStateException with actual cause?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants